The present invention relates to methods and apparatuses for improving network visibility in a network environment. More particularly, the present invention relates, in one or more embodiments, to improvements in configuring and managing network visibility infrastructures in a network environment.
A network is typically formed of, among others, a large number of switching resources (such as for example routers and switches) and links. Data, in the form of packets for example, may be sent through the links of the network. By configuring the switches appropriately, data packets may be sent from a given sender coupled to the network to a given receiver also coupled to the network although the sender and the receiver may be physically located far apart. The speed with which data packets are transferred from the sender to the receiver depends, in part, on the capacity and speed of the links as well as on the switching resources. The internet is an example of such a network and is well known, and thus its basic operating principles will not be discussed in great details herein.
Network Packet Brokers (“NPB”), network taps (“taps”), and mirroring ports on switching resources have long been incorporated into networks (such as internal networks and/or the internet) to facilitate processing of data packets and/or to route data packets to/from network monitoring tools. These monitoring tools may include, for example, network analysis tools, forensic tools, various network monitoring tools, firewalls, malware prevention tools, intrusion detection tools, etc.
Generally speaking, taps are implemented at specific points in the network to access the data traffic and pass the data (whether the original data packets or the replicated copies thereof) to the monitoring tools. NPBs, on the other hand, represent hardware and/or software modules that perform, among other tasks, aggregation of monitored traffic (which again can be the original data packets or replicated copies thereof) from multiple links/segments, filtering and grooming of traffic to relieve overburdened monitoring tools, load-balancing traffic across a pool of monitoring tools, and regeneration of traffic to multiple monitoring tools. Both taps and NPBs are available from vendors such as Ixia of Calabasas, Calif.
Mirroring ports are ports implemented on the switching resources and are configured to send replicated data packets that traverse the switching resources (which may be all traversing packets or a filtered set thereof).
To facilitate discussion, FIG. 1A shows the relationship between the production network 10, the network visibility infrastructure 20, and the network monitoring tools 30.
Production network 10 represents the network of switching resources and links that is configured to transport data between the sender and the receiver. Network monitoring tools 30 perform functions that are not directly related to the transport of packets through production network 10 but are nevertheless necessary to ensure optimum performance of production network 10. These network monitoring functions include for example security, application performance monitoring (APM), network performance monitor (NPM), malware detection, intrusion detection, as well as other network management tasks. The list above is not inclusive, and these network monitoring functions are known to those skilled in the art.
Network visibility infrastructure comprises for example the taps, the network packet brokers, and the mirroring ports (e.g., SPAN™ ports from Cisco Systems of San Jose, Calif.) that are disposed at various nodes in production network 10 to obtain data packets or copies thereof for use by network monitoring tools 30.
FIG. 1B shows a typical network configuration in which a plurality of network devices (such as routers or switches) 102A, 102B, 102C, 102D, 102E, 102F and 102G are shown communicatively coupled to NPB 104. These network devices represent some of the switching resources that direct traffic from one user to another via the network.
The couplings between network devices 102A-102C with NPB 104 are accomplished using respective mirroring ports 106A-106C (such as a SPAN or Switch Port Analyzer ports in the terminology of vendor Cisco Systems of San Jose, Calif.) on the network devices. Data packets traversing each of NDs 102A-102C may be replicated and provided to respective mirroring ports, which packets are then provided on respective links 108A-108C to respective ingress ports (not shown) of NPB 104. In this configuration, NPB 104 is said to be connected in an out-of-band configuration with respect to packets traversing NDs 102A-102C since the original packets continue on their way without traversing NPB 104 while NPB 104 receives the replicated packets from NDs 102A-102C for forwarding to one or more of the monitoring tools 122 and 124.
Packets traversing between ND 102D and ND 102E can be tapped by tap 110, which is coupled to both NDs 102D and 102E. In one example, the packets from NDs 102D and 102E may be duplicated by tap 110 and provided to NPB 104 via links 108D and 108E respectively. In this configuration, NPB 104 is said to be connected in an out-of-band configuration with respect to packets traversing NDs 102D and 102E since the original packets continue on their way without traversing NPB 104 while NPB 104 receives the replicated packets from NDs 102D-102E.
In another example, the packets from ND 102D may be intercepted by tap 108 and redirected by tap 108 to NPB 104 and from NPB 104 to one or more of the monitoring tools for further forwarding to an analysis tool (such as analyzer 120) before being routed to ND 102E if the result of the analysis indicates that such routing is permissible. Malware detection may be one such type of analysis. In this configuration, NPB 104 is said to be connected in an in-line configuration since NPB 104 is in the data path between ND 102D and ND 102E and packets must traverse NPB 104 before reaching the destination.
FIG. 1B also shows a port aggregator 126, which aggregates packet traffic from NDs 102F and 102G to provide the aggregated packets to NPB 104 via link 124. Again, NPB 104 can be connected in-line with respect to the communication between NDs 102F and 102G (i.e., NPB 104 can be in the network data path), or NPB 104 can be connected in an out-of-band manner with respect to the communication between NDs 102F and 102G (i.e., NPB 104 receives only the replicated packets and the original packets continue on their way without traversing NPB 104).
Although only a few of the switching resources (e.g., network devices) are shown in FIG. 1B, it should be understood that a typical network may involve hundreds or thousands of these switching resources. Configuring and managing such a large number of switching resources are huge problems for network operators, and thus network operators have turned to technologies such as Software Defined Networks (SDNs) to ease the task of configuring and managing the switching resources.
Generally speaking, SDN decouples the switching hardware (e.g., the actual packet processors or network processors that perform the switching) from the control plane (implemented at least by the operating system and may include applications). Without decoupling, each network resource (such as a switch or a router) would have its own forwarding hardware controlled by its own applications executing on its own operating system. Any change in the configuration and management of the network or links thereof tends to involve reconfiguring a large number of associated switching resources using local applications executed on each of the switching resources.
SDN implements an abstracted operating system/control module and applications are executed on this abstracted operating system. The switching hardware circuitry and some control logic (e.g., packet processors or network processors) are implemented locally at each of the switching resources. The applications/abstracted operating system communicate with the switching hardware at each of the switching resources via well-established standard, such as OpenFlow™ (Open Software Foundation (ONF), https://www.opennetworking.org).
In SDN, if a change needs to be made to an application and/or to the operating system, it is no longer necessary to make the change on each of the switching resources. Instead, the change can be made at the centralized applications and/or the abstracted operating system, thereby simplifying configuration and/or maintenance. To put it differently, SDN permits the network operator to configure and manage the switching resources of the network from a centralized location using a software-centric paradigm.
Although taps, network packet brokers, and mirroring ports are also disposed throughout the network, these network visibility resources are not considered switching resources and thus far, there has been no way to manage the network visibility infrastructures as an integrated network. There is, however, a need to also reduce the configuration and/or maintenance burden associated with implementing a large number of these network visibility resources over vast distances as well as to better integrate network visibility into network traffic management and routing. Addressing these needs is one among many goals of embodiments of the present invention.